REMARKS 

This is in response to the Office Action mailed on October 26, 2006. In the Office 
Action, Claims 1-20 were indicated as pending and rejected. With this Amendment, Claims 1, 4- 
9, 13-17, and 20 are amended, and Claims 1-20 are presented for reconsideration and allowance. 

Amendments to the Specification 
Applicant has amended the specification to remove the section heading 
"SUMMARY OF THE INVENTION" firom page 3, line 23 of the specification. Apphcant has 
amended the specification to insert a section heading "SUMMARY OF THE INVENTION" at 
page 6, between lines 8 and 9. This change does not introduce new matter. Entry of the changes 
to the specification is requested. 

Claim Rejections - 35 USC 1 12 
The Examiner rejected Claims 1-20 under 35 USC 112, second paragraph. Claims 
1, 4-9, 13-17, and 20 were rejected for reciting "and/or". Claims 5-7, 9, 14, and 16-17 were 
rejected for reciting the term "in a known way". With this Amendment, the Claims are amended 
to remove references to "and/or" and "in a known wa/'. Reconsideration of the rejections of 
under 35 USC 112, second paragraph, and allowance of Claims 1-20 are therefore requested. 

Claim Rejections - 35 USC 102 

Claims 1-20 were rejected under 35 USC 102(e) as anticipated by LeLeu US 
6,088,687. The Examiner indicated that LeLeu disclosed all the limitations of Claims 1-20. 

Independent Claim 1, however, includes limitations to a cache node that behaves 
like a debit node and that includes a debit gateway modifying a payment token assigned to each 
data packet received". These limitations of Claim 1 are not disclosed by LeLeu. 

Independent Claim 20 includes limitations to a cache node that includes a debit 
gateway allowing a payment token assigned to each data packet received to be modified so as to 
reduce an initial value of the payment token by an amount representing the cost of a cache 
operation. These limitations of Claim 20 are not disclosed by LeLeu. 



-12- 



For these reasons, independent Claims 1, 20, as well as dependent claims 2-19 are 
believed to be novel. Withdrawal of the rejections under 35 USC 102 and allowance of Claim 1- 
20 are therefore requested. There are also other features of the embodiments that are not taught 
by LeLeu described in more detail below. 

In the Applicant's Specification at page 3 line 14, mention is made of "WO 
9733404 LELEU". The disclosure of WO 9733404 is fully the same as the disclosure of LELEU 
US 6,088,687. The Examiner has thus based the present rejections under 35 USC 102 on a prior 
art document which is discussed in the present application as a problem that one or more of the 
present embodiments improves upon. 

The presently disclosed embodiments relate to a payment process and system for 
operations within a data packet transmission network, and particularly, but not exclusively, 
Internet type networks. 

In the Applicant's specification, starting at mid-page 2, the prior art Leleu patent 
document is discussed. As explained in the specification, it seems difficult, if not impossible, to 
implement conventional payment technologies on the Intemet network for operations carried out 
on the networks. Indeed the Intemet network does not have the centralized administration 
necessary to implement these conventional payment technologies, which mainly comprise billing 
as a function either of the length of connection between units (for a preset data transmission 
speed and distance), or of the amount of data exchanged between two units (taking into account 
the data transmission speed). 

For this reason, the current technology of paying for operations carried out on the 
Intemet network comprises billing only for access at a physical point on the network. As shown 
in Leleu patent document, this billing is either at a flat-rate, or it takes into account the amount of 
data sent to the whole network, or else the totality of the data received from the totality of the 
network. 

Unfortunately, this prior art payment technology does not allow fair and equitable 
billing of transmission or service operations carried out within the Intemet network. Indeed, 
currently, the billing of transmission or service operations is not a function of the path traversed 
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by and of the transmission speed of the data packets. 

Therefore, in the Leleu reference, a technology ("token technology') is introduced 
that is based on the insertion of payment tokens in the packet stream and allows each data packet 
conveyed by the network to settle for itself the cost of a transmission operation relating to its own 
transport, or the cost of a service operation relating to its own container or content. 

The general design of existing token technology is described in our application 
from page 3, line 24 to page 5 line 6. As explained there, this token technology has numerous 
advantages. Li particular, it allows fair and equitable billing of transmission and/or service 
operations carried out within a data packet transmission network, for example of the Litemet 
type. It may also constitute an electronic payment process, associated with the content of the 
packets, in the network nodes. Indeed, the payment token assigned to each data packet makes it 
possible to finance any type of operation (transport and/or service) carried out by the destination 
unit or any network node in which the packet will reside. 

However, the token technology, as taught by LeLeu, has the major drawback of 
not covering the situation, which is, however, increasingly frequent, where a cache unit is 
located, within the network, between the unit including the credit gateway (source unit or credit 
node) and the unit including the debit gateway(destination unit or debit node). 

Conventionally, a cache unit (also called a cache node) stores responses (web 
pages, in the case of the Internet) to the most frequent requests to different end sites. Thus, when 
it receives a request for which it has previously stored the response, the cache unit itself sends the 
response to the customer sending said request. In this way the number of requests actually passed 
on to the end sites is restricted, and response times are therefore reduced. Typically, the cache 
unit is a "proxy" server. 

Token technology, as taught by LeLeu, makes no provision however in the 
situation where a cache unit carries out one or more operations on behalf of another unit 
(destination unit or debit node) located downstream. This function that the debit gateway 
included in this other unit never receives some data packets (corresponding to requests not 
passed on to the end sites), and especially does not receive the payment tokens assigned to the 
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latter. In other words, it was impossible to apply token technology when a cache unit is used, an 
embodiment of the present disclosure overcomes this major drawback of this prior art. 

To be more exact, an embodiment of the present disclosure provides a payment 
process and system constituting an efficient improvement on the LeLeu token technology 
discussed just above, so that the latter may be appHed even when a cache unit is used. 

An embodiment of the present disclosure provides such a payment process and 
system, allowing the replaced unit or node (destination unit or debit node) to be informed about 
and to control the collection of tokens which are intended for it, even though it does not carry out 
this collection itself 

An embodiment of the present disclosure provides such a payment process and 
system, including a service continuity test mechanism. 

These functions, and others which will emerge subsequently, are met according to 
an embodiment of a payment process for transmission and/or service operations carried out 
within a data packet transmission network, during a session between a source unit and a 
destination unit interconnected via at least one node of said network, said destination unit and/or 
said at least one node being used by at least one operator and/or at least one service provider. The 
process is of the type implementing token technology as mentioned above. 

According to certain aspects, between said source unit and said destination unit, at 
least one node is used as a cache node, including caching that allows at least one cache operation 
to be carried out, on behalf of at least one replaced unit or node, namely said destination unit or 
at least one node, located downstream of said at least one cache node. Furthermore, said at least 
one cache node also behaves like a debit node, and includes a said debit gateway modifying the 
payment token assigned to each data packet received so as to reduce said initial value of the 
payment token, by an amount representing the cost of said at least one cache operation carried 
out, for said packet received, by said cache node. Lastly, a manager of said at least one cache 
node receives from said toll center, for each packet received during said session, said financial 
settlement of said representative amount and restores it to a manager of said at least one replaced 
unit or node, or allows a manager of said at least one replaced unit or node to receive directly 
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said financial settlement. 

The general principles comprise including in the cache node a debit gateway 
which replaces, for the collection of tokens, the debit gateway of the replaced unit or node. A 
financial settlement of tokens thus collected may be requested fi-om the toll centre, to the 
advantage (directly or via the cache node) of the replaced unit or node. 

hi this way, the tokens may be collected even though they do not quite reach the 
replaced xmit or node. Li other words, certain aspects of the embodiments allow token technology 
to be applied even though a cache unit is used. 

hi addition to the features described above, there are further advantages that can 
be seen in the embodiments. 

LeLeu describes a mechanism where an end-user knowing the total price of a 
service associated to a packet, can send a packet with a token containing some pieces of data, that 
can be extracted by the different devices involved in the processing of a packet, in order to be 
compensated by a centralized system. But, LeLeu presents several important limitations such as 
the following: 

- the token carries only a numerical value of a credit, but no information about the 
user or the expected service, 

- most services charges cannot be derived fi-om the content of a packet. So 
additional information is required to determine what needs to be charged, (profile, bonus, client 
identifier, ...), 

- in most networks and in Internet in particular, a packet does not allow to identify 
an end-user, nor all the devices traversed, so no error handling mechanism can rely solely on a 
packet and the associated numerical value. 

Unlike LeLeu, the embodiments enrich the token with a bit of information that 
allows charging the end-user with more complex charging model than the sole metering scheme 
that is the target of Leleu disclosure, an in effect the only model his disclosure allows for. 
hi addition, the following is noted concerning LeLeu's teachings: 
From column 2, line 3, to column 3, line 12, Leleu describes how a data packet 
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carried on a network pays for its transmission cost, or the cost of services and operations 
associated to the packet. For this very reason, the embodiment rehes on the transmission with the 
packet of a "toll token" which carries (col.2, line 10) a numerical value that can be authenticated, 
and which is difficult to forge. 

The various devices traversed are expected to validate the packet and to modify 
the token in such a way that they reduce its value. The provider can later on derive some revenue 
from a centralized system which provides the basic components of the token to the end user who 
sends the packet in the first place. 

Also, column 2, line 50, we can read that the device or system, can calculate the 
value corresponding to the toll-unit credit as a function of the destination address of the packet. 

In that case, it is clear that this entails the end-user must be able to compute in 
advance the price of the service. This view corresponds to the initial metering model that the 
author has in mind. Data services have more complex charging mechanisms where the charge 
associated to a transaction (some type of processing triggered by the packet) can depend on many 
other parameters such as customer profile, time of day, accumulated bonus). 

As already explained the purpose of our improvement to disclosure of Leleu 
patent, is to allow a Token Based charging system to perform those types of charging as well. For 
this, we suggest to include in the Token itself some associated information which will allow the 
various devices to compute which price they must apply based on the nature of this associated 
extra information. 

From column 3, line 50 to column 4, line 5, it is clearly stated that different types 
of operations can be charged according to Leleu disclosure. We never claim this; our key point is 
that such systems (for example, charging for Java code execution as given in the example at 
column 12, hne 15) usually need more information than what is included in a packet itself to 
derive what is to be charged, hicluding a piece of information in the packet helps to determine 
what must be charged and this is a definite advantage as it removes the burden on the end-server 
to initiate a request to the network operator to find out about this information directly. 

It should be noted in addition that a single data packet does not usually allow an 
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end server to identify the initial sender of this packet let alone because of the network operator 
firewalls. So we can see that without additional information carried in the token as claimed in our 
application, no customer specific charging can be done. 

At column 4, lines 20-55, we can see, in particular at line 31, confirmation that for 
Leleu, the credit amount to be included in the packet must correspond to the cost of the 
operations to be performed on the data packet. This is reinforced at column 10, line 28, where it 
is said that the packet arrives with a token containing more credit that it can debit, then an error 
must be sent back. 

Here we see an actual key limitation of Leleu disclosure. As the end-server is 
unable to identify the source of the transaction (which he takes money from), he must have an 
error mechanism in case the money sent does not exactly cover the expected price. In addition it 
should be noted that there is no protocol described in Leleu document suggesting how this error 
handling system could operate. For example, in the Intemet, not a packet (or the information in 
the Token) contains any information allowing an end-system to know who is the sender of the 
packet, nor what are the intermediate devices that the packets traversed before arriving to the 
end-server. This is obviously a major issue in the embodiments proposed by Leleu. As a matter 
of fact, when you send money, there is no way to get your money back in case of problem, nor to 
know what element in the chain of devices caused the transaction to abort (hence no way to know 
who to complain to). 

Column 6, line 58, to column 8, hne 37 and column 9, line 30 to column 10, line 
50, describe in detail the operation of Leleu disclosure, without addressing the issue identified 
above. 

In addition to the need to include a piece of information in a packet to give 
enough information to all intermediate devices to compute a price, we clearly state that the end 
user does not need to provide the exact amount of the transaction. 

With some information in the packet, the end-server can either charge more or 
less than what is included in the packet, using the information to collect money fi-om an account, 
or getting back to the operator based on the included information. 
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Furthermore, we claim that the end-server can also use the information added to 
the token to adapt the content to the end-user. An example could be to change the quality of a 
delivered video service, based both on the token information and the credit value included. 

Concluding Remarks 
The Application appears to be in condition for allov^ance and favorable action is 
requested. The Director is authorized to charge any fee deficiency required by this paper or credit 
any overpayment to Deposit Account No. 23-1 123. 
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